1. Field of the Invention
This invention relates generally to piconet wireless networks. More particularly, it relates to a more secure pairing process in a piconet network such as a BLUETOOTH™ type piconet network.
2. Background
Piconets, or small wireless networks, are being formed by more and more devices in many homes and offices. In particular, a popular piconet standard is commonly referred to as a BLUETOOTH™ piconet. Piconet technology in general, and BLUETOOTH technology in particular, provides peer-to-peer communications over short distances.
The wireless frequency of the piconets may be 2.4 GHz as per BLUETOOTH standards, and/or typically have a 20 to 1000 foot range. The piconet RF transmitter may operate in common frequencies which do not necessarily require a license from the regulating government authorities, e.g., the Federal Communications Commission (FCC) in the United States. Alternatively, the wireless communication can be accomplished with infrared (IR) transmitters and receivers, but this is less preferable because of the directional and visual problems often associated with IR systems.
A plurality of piconet networks may be interconnected through a scatternet connection, in accordance with BLUETOOTH™ protocols. BLUETOOTH network technology may be utilized to implement a wireless piconet network connection (including scatternet). The BLUETOOTH standard for wireless piconet networks is well known, and is available from many sources, e.g., from the web site www.bluetooth.com.
As part of an initial communication between BLUETOOTH devices, the BLUETOOTH devices within range of one another perform what is known in the art as “pairing”.
FIG. 7 depicts a conventional BLUETOOTH device 500.
In particular, as shown in FIG. 7, a conventional BLUETOOTH device 500 includes a processor or logic device 508 (e.g., a microprocessor, a microcontroller, or a digital signal processor (DSP)), and a BLUETOOTH front end 504. Moreover, the BLUETOOTH device 500 includes a unique 48-bit BD_ADDR 502, and a table 506 containing a list of paired BLUETOOTH devices in the particular piconet. The paired device unique address table 506 may be pre-configured at the factory, or written to by a suitable user interface such as a software-based configuration module 510 allowing entry of the 48-bit address of paired devices for storage in the paired device unique address table 506.
When configuring a BLUETOOTH device in a BLUETOOTH piconet, the devices communicating on the piconet must know the specific unique 48-bit address of matching devices on the piconet. For instance, it may be desirable for entertainment devices (e.g., TV, radio, CD player, DVD player, MP3 player, etc.) having BLUETOOTH communication capabilities to communicate with one another, but it may not be desirable (nor make sense) for appliances such as a stove or refrigerator, toaster, blender, etc. having BLUETOOTH communication capabilities talk with entertainment devices.
This is particularly true since the maximum number of BLUETOOTH devices in a piconet is somewhat restricted. For instance, current BLUETOOTH standards permit one (1) master and seven (7) slaves to be active in the piconet at any one time (plus a number of BLUETOOTH devices being capable of being ‘parked’).
According to the standard, all BLUETOOTH devices are assigned a unique 48-bit BLUETOOTH device address (BD_ADDR). This address is derived from the IEEE802 standard, and is divided into three fields: a lower address part (LAP) comprising 24 bits; an upper address part comprising 8 bits; and a non-significant address part (NAP) comprising 16 bits. The LAP and UAP form the significant part of the 48-bit BLUETOOTH device address (BD_ADDR). The total address space obtained is 232.
The BLUETOOTH device address (BD_ADDR) is unique for each BLUETOOTH device. The BLUETOOTH addresses are publicly known, and can be obtained by a manufacturer via MMI interactions, or, automatically, via an inquiry routine by a BLUETOOTH device. Blocks of 48-bit addresses may be assigned to various manufacturers, who in turn factory pre-configure each BLUETOOTH device to include a unique 48-bit address (BD_ADDR) as well as a table of unique 48-bit addresses of ‘paired’ devices which will all communicate over a common piconet.
When a user buys or replaces a BLUETOOTH equipped electronic device, the user must configure the new BLUETOOTH device for communication with relevant and desired devices in the relevant piconet. Moreover, to provide a certain level of security, the BLUETOOTH protocol provides for encryption of data passed therebetween. To this end, there are a number of different link and encryption keys currently used in BLUETOOTH, all of which are collectively referred to herein as ‘data keys’.
For instance, link keys are used as authentication keys between BLUETOOTH devices, and to generate encryption keys.
A master key is used for point to multi-point communications, and may replace for a time the current link key.
A unit key is a semi-permanent, often ROM-based key generated in every single unit often only once during factory setup. Though unlikely, the unit key might be exchanged at any time.
A combination key is dependent on two BLUETOOTH devices. Each device produces and sends a random number to the other, and a new 128 bit combination key is derived using a SAFER+ algorithm. A combination key is often created toward the end of unit pairing.
A 128 bit initialization key is a link key used for a single session, and is created each time the BLUETOOTH device is initialized. An initialization key is used only when no combination keys or unit keys have been exchanged yet. An initialization key is often created toward the beginning of unit pairing.
An encryption key is derived from the current link key, and is used by an encryption engine to produce encrypted data.
FIG. 8 depicts the authentication process and subsequent link key process between two BLUETOOTH devices.
To communicate, both BLUETOOTH devices 602, 604 must share the same secret key. The secret key can be built in by manufacturers (a fixed key), or could be derived from a Personal Identification Number (PIN) or BLUETOOTH passkey.
To begin communicating with one another, the BLUETOOTH devices 602, 604 bond by having link managers in the respective devices 602, 604 verify with one another that they share a secret key through a process called authentication. While often time authentication takes place at link setup, it need not. After authentication, the link managers of the respective devices 602, 604 create and exchange a link key. The process of authentication and link key generation are collectively called BLUETOOTH bonding or pairing.
If the BLUETOOTH devices 602, 604 determine that they share the same secret key, then they go on to use their shared secret key to generate a link key and ultimately to encrypting traffic on the link.
The present inventors have appreciated that there is a weakness in the BLUETOOTH specification that might allow an adversary to steal the keys used for authentication and encryption that are intended to keep BLUETOOTH communications secure.
FIG. 9 depicts the range of wireless communications between two BLUETOOTH devices during conventional pairing operations.
In particular, FIG. 9 depicts two conventional BLUETOOTH devices 909a, 909b communicating using conventional BLUETOOTH RF messages during pairing, including the transmission of link keys. However, it is contemplated that a BLUETOOTH identity thief 902 might have a BLUETOOTH sniffer 900 be within range 950 of the BLUETOOTH devices 909a, 909b during their pairing process. The information gained by the BLUETOOTH sniffer 900 can prove disastrous to the users of the BLUETOOTH devices 909a, 909b. 
For instance, an attack might be made during the initial pairing of two BLUETOOTH devices 602, 604 that enables the adversary to intercept keys over the air and thereafter eavesdrop on future connections. Though BLUETOOTH transactions used for mobile commerce (m-commerce) that require a high level of security would most assuredly have greater security imposed by a higher layer (i.e. application layer using SSL, RSA, etc.) this security weakness in BLUETOOTH makes the user vulnerable to attack in two ways. First he or she could be impersonated by one who has intercepted the device addresses and keys. Possible examples would be impersonating a person's headset and stealing cellular air time or impersonating a person's laptop and stealing dial-up network access from the cell phone or stealing address book information.
Moreover, it is possible for an unauthorized receiver to eavesdrop on information passed between two (or more) BLUETOOTH devices 602, 604. Examples of the type of information would be non-encrypted e-mail, web sites being accessed, or even which stock quotes were being requested. Though some of this may not seem very important to some, it has the potential of providing an unfair and generally illegal advantage, particularly in the corporate or business world.
One possible way around the vulnerability of BLUETOOTH devices during pairing might be for a manufacturer to provide previously and permanently paired devices, paired in the secrecy and security of the manufacturing facility. However, such predetermined and/or dedicated pairing would tend to restrict use of the BLUETOOTH devices such that they would work only with other devices sold by the same manufacturer.
There is a need for a more secure pairing technology and apparatus with respect to piconet devices in general, and BLUETOOTH™ piconet devices in particular.